home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 130 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.6 KB
  1. Date: Tue, 31 May 1994 14:22:28 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour. 
  4. To: gem-list@world.std.com
  5. In-Reply-To: <9405311101.AA19032@phlem.ph.kcl.ac.uk>
  6. Message-Id: <Pine.3.87.9405311428.G24733-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. If the manager handles palette changes automatically, then
  11.  
  12. there is no need for the app to deliberately register with the manager.
  13.  
  14. Using facilities in the manager for getting help with building a palette 
  15. would simply set the palette with VDI.  Only the app with the window on 
  16. top is allowed to make palette changes, using the manager or not.
  17.  
  18. The manager would need to LEARN a particular window's palette just before 
  19. it's untopped, because the app may change the palette multiple times 
  20. while the window is on top.
  21.  
  22. ---
  23.  
  24. The only argument in favor of registering with the manager is for the 
  25. case where an app sets a palette and expects all of its windows to use 
  26. that same palette.  An app would register its 'awareness' with the 
  27. manager. (by appl_id)
  28.  
  29. an 'aware' app would have palettes switched by the window.
  30.  
  31. an 'unaware' app would have palettes switched by the application, 
  32. regardless of which window.
  33.  
  34. The manager would need to determine which app is being made active, as 
  35. well as which window, and for unaware apps, the manager would have to 
  36. manage the palette for the app even if it didn't open a window.
  37.  
  38. This gets to be a bit complicated, but I'm sure we can simplify it well 
  39. enough.
  40.  
  41. As they say, the rule of KISS, "Keep It Simple, Stupid!"
  42. We don't want to be entrapped by the Microsoft/IBM/Intel "make it as 
  43. complicated as possible" syndrome.
  44.  
  45.  
  46.